Problem

The _initialize_devices() retry loop polls until all family members leave the LOADING state or _MAX_REFRESH_RETRIES is exhausted. Family members with location sharing disabled (e.g. a Mac where the user has turned off Share My Location) return deviceFetchStatus: LOADING permanently — they never resolve.

This caused the loop to always exhaust all 5 retries and log:

Max retries reached when fetching family devices

on every single poll cycle, generating constant log noise and unnecessary API calls.

Root cause

The loop only tracked retry count, not whether any progress was made between retries. A permanently-stuck member looks identical to a slow-resolving member until all retries are spent.

The FMIP membersInfo payload contains no field indicating whether a member has location sharing enabled (only accountFormatter, firstName, lastName, deviceFetchStatus, useAuthWidget, isHSA, appleId), so the member cannot be filtered out by capability.

Fix

Track which member keys are LOADING between retries. If the set of LOADING members hasn't changed after a retry, those members will not resolve on further retries — stop early.

Retry 0: {MacBook} LOADING → retry (progress possible)
Retry 1: {MacBook} LOADING → same as before → stop

For a transient member that does resolve (e.g. an iPhone waking up):

Retry 0: {iPhone, MacBook} LOADING → retry (progress possible)
Retry 1: {MacBook} LOADING → set changed → retry (iPhone resolved!)
Retry 2: {MacBook} LOADING → same as before → stop

Result

• Permanently-stuck members cause at most 2 retries (vs. always 5) before exiting cleanly
• Transient members that do resolve still get up to _MAX_REFRESH_RETRIES attempts
• No more "Max retries reached" log spam on every poll cycle
• Tested with Home Assistant 2026.4.3, family account with one member (Mac) that has location sharing permanently disabled

Type of change

• Bug fix (non-breaking change which fixes an issue)

Co-authored with Claude Sonnet 4.6